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SPECIFICATION 
TO ALL WHOM IT MAY CONCERN: 

Be it known that we, Stephen M. Blanding, a citizen of 
the United States, residing at 22311 NE 62nd Place, Redmond, 
Washington 98053, Michael J. Cherry, a citizen of Canada, 
residing at 17537 NE 142nd Street, Redmond, Washington 98052, 
David E. Kays, Jr., a citizen of the United States, residing 
at 1111 W. Lake Sammamish Parkway SE, Bellevue, Washington 
98008, James S. Masson, a citizen of the United States, 
residing at 12114 NE 171st Place #F304, Bothell, Washington 
98011, Debi P. Mishra, a citizen of India, residing at 15306 
N.E . 63rd Way, Redmond Washington 98052, and Daniel Plastina, 
a citizen of the United States, residing at 4409 229th Place 
SE, Issaquah, Washington 98029, have invented a certain new 
and useful METHOD AND SYSTEM FOR MANAGING LIFECYCLES OF 
DEPLOYED APPLICATIONS of which the following is a 
specification. 



METHOD AND SYSTEM FOR MANAGING LIFECYCLES OF DEPLOYED 

APPLICATIONS 

FIELD OF THE INVENTION 

5 The invention relates generally to computer systems and 

application programs, and more particularly to the deployment 
of application programs across a network of computers. 

BACKGROUND OF THE INVENTION 

10 Centralized application deployment in computer networks, 

such as provided in Windows® 2000 Server, enables 
administrators to specify which application programs client 
users and machines will have in accordance with a policy. 
More particularly, at the time of user logon, machine startup 

15 and/or connection to the network, and/or periodically while 
the machine is connected, a list of applications that are to 
apply to the user or machine is processed. The list is 
dynamically evaluated against the state of the machine, e.g., 
at the time of user logon or machine connection, to establish 

20 which applications are available to the user based on the 

user's credentials and to the machine based on its identity. 
Then, a process takes the actions necessary to match the 
client to the list. Such state-based application deployment 
provides administrators with a great deal of centralized 

25 control of an enterprise's computing resources. 
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However, while this works well in a static environment/ 
in typical enterprises, the applications assigned to users and 
machines often change. For example, the set of deployed 
applications is dynamic as new applications and alternative 
5 (e.g., upgraded) versions of existing applications are 

regularly being introduced. At the same time, administrators 
working independently from one another determine which 
applications a given machine or user will have. This may lead 
to a client having application programs that are mutually 
£3 10 exclusive with one another from the enterprise's perspective, 
fU e.g., two spreadsheet application programs or versions are 
UJ available, even though both should not be installed at the 
^ same time. The possible permutations for an enterprise are 

numerous and continuously evolving, for example, whether users 

..E 

£15 should have one word processing application, two word 

; jq processing applications, or both, along with which version. 

Another consideration is whether users should be forced to use 
one application or version thereof, or another, or whether the 
user has an option to choose. Making custom modifications for 
20 each user each time the user wants to make an optional change 
is impractical in large enterprises. 

Moreover, at times, administrators may not want to make a 
drastic change to the applications that are deployed, but 
rather would like to implement a change slowly, such as only 
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to a small group of users initially. In that way, any 
problems that arise are isolated during a trial period. Then, 
after the smaller test corrects any problems, or shows that 
the problems are acceptable, the application is rolled out to 
5 a larger group. If the application is acceptable after 

testing on the larger group, the application is deployed to 
the entire enterprise. Again, in each scenario, the change 
may be forced or optional for a period of time. 

In sum, applications may be deployed across a network in 
y 10 numerous ways. The manual method of configuring each computer 

for a given user or machine is burdensome and inadequate for 
\Ji larger networks. However, state-based deployment has 

i'n heretofore not provided an adequate way to determine which 

Q application should apply to a user in the event that one or 

M= 15 more similar applications apply. 

u 

SUMMARY OF THE INVENTION 

Briefly, the present invention provides a system and 
method for managing the lifecycles of applications used in an 
20 enterprise, by setting precedence relationships among 

applications deployed in a network to determine a set of 
applications to apply to each client user or machine. 
Information indicative of precedence relationships between 
applications is specified and maintained at a network 
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location, and an application to potentially deploy, such as 
during user logon, is selected. A determination is made as to 
whether the application has precedence over another 
application, and if so, the selected application is set for 
5 deployment while the other application is deselected. 

The method and system facilitate the use of application 
lifecycles, a model for replacing applications with either new 
or updated applications . To this end, upgrades may be 
optional or mandatory, provided first as a pilot to a small 

10 group of users, rolled out to a larger group, and/or then 
provided to all users. The application programs that are 
replaced may be removed and then replaced, or overlaid by 
installing the new application over the old. Other 
applications may simply be removed without replacing, while 

15 others may be allowed to optionally remain but be non- 
supported. 

Other advantages will become apparent from the following 
detailed description when taken in conjunction with the 
drawings, in which: 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 is a block diagram representing a computer 
system into which the present invention may be incorporated; 
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FIG. 2 is a block diagram representing various components 
for centralized application deployment in a network and for 
managing relationships among deployed applications in 
accordance with one aspect of the present invention; 
5 FIG. 3 is a representation of a policy and class store 

architecture for centralized application deployment; 

FIG. 4 is a block diagram generally representing 
exemplary components for state based deployment including 
upgrading and on-demand installation of applications in 
10 accordance with one aspect of the present invention; 

FIG. 5 is a representation of the set of applications in 
an enterprise and subsets thereof available to users, along 
with upgrade relationships therebetween; 

FIG. 6 is a block diagram representing various components 
15 for upgrading applications based on policy settings and the 
state of the machine in accordance with one aspect of the 
present invention; 

FIG. 7 is a diagram representing a lifecycle of a typical 
deployed application program in accordance with one aspect of 
20 the present invention; and 

FIGS. 8-10 comprise a flow diagram generally 
representing the steps taken to upgrade application programs 
in accordance with one aspect of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



Exemplary Operating Environment 

FIGURE 1 and the following discussion are intended to 
provide a brief general description of a suitable computing 
environment in which the invention may be implemented . 
Although not required, the invention will be described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a personal computer. 
Generally, program modules include routines, programs, 
objects, components, data structures and the like that perform 
particular tasks or implement particular abstract data types* 
Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system 
configurations, including hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe computers 
and the like. The invention may also be practiced in 
distributed computing environments where tasks are performed 
by remote processing devices that are linked through a 
communications network. In a distributed computing 
environment, program modules may be located in both local and 
remote memory storage devices. 

With reference to FIG. 1, an exemplary system for 
implementing the invention includes a general purpose 



computing device in the form of a conventional personal 
computer 20 or the like, including a processing unit 21, a 
system memory 22, and a system bus 23 that couples various 
system components including the system memory to the 
5 processing unit 21. The system bus 23 may be any of several 
types of bus structures including a memory bus or memory 
controller, a peripheral bus, and a local bus using any of a 
variety of bus architectures. The system memory includes 
read-only memory (ROM) 24 and random access memory (RAM) 25. 

10 A basic input/output system 26 (BIOS), containing the basic 
routines that help to transfer information between elements 
within the personal computer 2 0, such as during start-up, is 
stored in ROM 24. The personal computer 20 may further 
include a hard disk drive 27 for reading from and writing to a 

15 hard disk, not shown, a magnetic disk drive 28 for reading 
from or writing to a removable magnetic disk 29, and an 
optical disk drive 30 for reading from or writing to a 
removable optical disk 31 such as a CD-ROM or other optical 
media. The hard disk drive 27, magnetic disk drive 28, and 

20 optical disk drive 30 are connected to the system bus 23 by a 
hard disk drive interface 32, a magnetic disk drive interface 
33, and an optical drive interface 34, respectively. The 
drives and their associated computer-readable media provide 
non-volatile storage of computer readable instructions, data 
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structures, program modules and other data for the personal 
computer 20. Although the exemplary environment described 
herein employs a hard disk, a removable magnetic disk 29 and a 
removable optical disk 31, it should be appreciated by those 
5 skilled in the art that other types of computer readable media 
which can store data that is accessible by a computer, such as 
magnetic cassettes, flash memory cards, digital video disks, 
Bernoulli cartridges, random access memories (RAMs), read-only 
memories (ROMs) and the like may also be used in the exemplary 

10 operating environment. 

A number of program modules may be stored on the hard 
disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, 
including an operating system 35 (preferably Windows® 2000) , 
one or more application programs 36, other program modules 37 

15 and program data 38. A user may enter commands and 

information into the personal computer 20 through input 
devices such as a keyboard 40 and pointing device 42. Other 
input devices (not shown) may include a microphone, joystick, 
game pad, satellite dish, scanner or the like. These and 

20 other input devices are often connected to the processing unit 
21 through a serial port interface 46 that is coupled to the 
system bus, but may be connected by other interfaces, such as 
a parallel port, game port or universal serial bus (USB) . A 
monitor 47 or other type of display device is also connected 



to the system bus 23 via an interface, such as a video adapter 
48. In addition to the monitor 47, personal computers 
typically include other peripheral output devices (not shown) , 
such as speakers and printers, 
5 The personal computer 20 may operate in a networked 

environment using logical connections to one or more remote 
computers, such as a remote computer 49. The remote computer 
4 9 may be another personal computer, a server, a router, a 
network PC, a peer device or other common network node, and 
O 10 typically includes many or all of the elements described above 
! j* relative to the personal computer 20, although only a memory 

storage device 50 has been illustrated in FIG. 1. The logical 
connections depicted in FIG. 1 include a local area network 
q (LAN) 51 and a wide area network (WAN) 52. Such networking 

jdk 15 environments are commonplace in offices, enterprise-wide 
C 5 computer networks, Intranets and the Internet. 

When used in a LAN networking environment, the personal 
computer 20 is connected to the local network 51 through a 
network interface or adapter 53. When used in a WAN 
20 networking environment, the personal computer 20 typically 
includes a modem 54 or other means for establishing 
communications over the wide area network 52, such as the 
Internet. The modem 54, which may be internal or external, is 
connected to the system bus 23 via the serial port interface 
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46. In a networked environment , program modules depicted 
relative to the personal computer 20, or portions thereof, may 
be stored in the remote memory storage device. It will be 
appreciated that the network connections shown are exemplary 
and other means of establishing a communications link between 
the computers may be used. 

The present invention is described herein with reference 
to the Microsoft® Windows® 2000 operating system, and in 
particular to the flexible hierarchical structure of sites, 
domains and/or organizational units of a Windows® 2000 Active 
Directory 60 of a domain controller 61 (FIG. 2) . 
Notwithstanding, there is no intention to limit the present 
invention to Windows® 2000 (formerly Windows NT®) or the 
Active Directory 60, but on the contrary, the present 
invention is intended to operate with and provide benefits 
with any operating system, architecture and/or mechanisms that 
utilize network information. 

APPLICATION DEPLOYMENT 

Turning to FIG. 2, in general, application deployment 
involves initially making an application available to network 
policy recipients via group policy objects 62. To this end, 
an administrator tailors policy objects 62 to sites, domains, 
and/or organizational units of users and computers thereunder, 



(in a hierarchical manner), by specifying one or more group 
policies 62 therefor, such that the policy within an 
organization is centrally managed. Such group policies 62, 
including the prioritizing of multiple policies 62 for policy 
5 recipients (e.g., users or machines) are described in U.S. 

Patent Application Serial No. 09/134,805, entitled ^System and 
Method for Implementing Group Policy," assigned to the 
assignee of the present invention and hereby incorporated by 
reference herein in its entirety. 

10 A significant policy consideration that may be 

implemented under a group policy 62 is the management of 
applications. If application management is set up for a group 
policy object 62, a class store 64 is created thereunder, 
essentially to store the state of deployment of managed 

15 applications. More particularly, the first time the policy 
administrator attempts to deploy an application under the 
group policy object 62, a class store 64 is created, and thus 
the existence of a class store 64 in a group policy object 62 
indicates that application management is in effect for this 

20 group policy 62. In a preferred embodiment, the class store 
64 uses the Windows® 2000 Active Directory 60 as its 
centralized store and ties into the administrative hierarchy 
defined thereby, i.e., the class store is a container object 
(objectClass = ClassStore) in the Active Directory 60. Note 



that although separately shown in FIG. 2 for purposes of 
simplicity, a class store 64 is actually a subcontainer of the 
group policy container 62, as described in more detail in co- 
pending United States Patent Application Serial No. 09/158,023 
5 entitled m Class Store Schema/' assigned to the same assignee 
as the present invention, and hereby incorporated by reference 
herein in its entirety. 

The class store 64 is the component that provides the 
framework for deploying application resources in the Active 
,*J.O Directory 60 and making the deployment policy available to 
5j policy recipients {i.e., users and machines) via group policy 
yj objects. In this manner, applications and/or components in a 
fU class store are available as needed, while updates to 
^ components and/or applications may be performed once in a 
415 centralized location. For example, in accordance with a 
% policy set by an administrator, and as described in detail 
-sbf below, users may automatically obtain new versions of 

applications and components as they become available. Access 
and administration privileges are controlled by standard 
20 access control properties on the class store container object 
64. 

FIG. 3 shows a directory container 68 and associated 
group policy object 62 having various containers under a class 
store 64, including an application package container 70, 



object class container 72 and component categories container 
74. The Class Store object 64 is the top-level container of a 
Class Store hierarchy. Applications and components are 
generically referred to as packages, and as shown in FIG. 3, 
5 are stored and cataloged under the class store 64, Packages 
may be available from various vendors for different platforms, 
activation modes, access control, setup, and installation 
information. For example, a package may include an entire 
application (e.g., Microsoft® Word or Excel), a set of binary 
JLO component implementations packaged together, or a standalone 
jrj COM component (e.g., an ActiveX™ control) . 

The class store 64 may include a variety of properties 
and relationships for each of its various application 
a! packages. In general, these include the deployment state of 
|E5 the application, global details such as deployment name, 
GH publisher of the application, version, and a source for 
■■0 additional information. Also included is installation 

specific information, used for causing the application to be 
partially or fully installed on a desktop, activation specific 
20 information, used for finding the correct application to 
launch for an OLE or Shell activation, including, ClassID, 
File Extension and ProgID associations of the application. 
Platform specific information is also included, providing 
information on which hardware architecture and what operating 
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system (and versions thereof) are required to run the 
application, along with specifying a set of supported 
languages. Moreover, in accordance with one aspect of the 
present invention and as described in more detail below, 
upgrade relationships with other applications may be included. 

The class store 64 and the containers 70, 72 and 74 
thereunder thus provide the information for deploying 
applications in a network. In particular, two mechanisms for 
deploying applications are supported, referred to as Assigning 
and Publishing, as described in U.S. Patent Applications, 
Serial No. 09/158,968 entitled ^Method and System for 
Assigning and Publishing Applications" and Serial No. 
09/158,967 entitled ^Method and System for Advertising 
Applications," assigned to the Assignee of the present 
invention, and hereby incorporated by reference herein in 
their entireties. An application typically is assigned to a 
group of users (or a group of machines) when it is deemed 
mandatory for that group to have that application, while 
published applications are those that are made optionally 
available to users who may benefit therefrom. For example, 
the same version of an electronic mail application program may 
be assigned to everyone in an organization, while a word 
processing program may be assigned to every group of users 
that needs some word processing capabilities. However, an 



application program for editing images may not be needed by 
everyone, and thus such a program may be published on a per- 
group basis so that those groups of users who may benefit from 
the program have it, while others who do not need it will not 
5 have it occupy resources of their workstations. 

Thus, an assigned application is an application that is 
explicitly made available to users in a group or 
organizational unit into which it has been deployed, and the 
user is not required to perform any special action to get an 
10 assigned application. To this end, as shown in FIG. 4, using 
an application deployment editor 76, (sometimes referred to as 
the Software Installation Snap- in ) , an administrator selects a 
package 78 to assign to a group, and via an API 80, generates 
at least one advertise script 82a therefor and writes it to a 
15 group policy object 60. At user logon, as part of a logon 

process 84, one or more group policy objects 62 are ordinarily 
applied to the user that is logging on, which includes 
executing at least one advertise script copy 82b therefor. 
Executing the advertising script 82b (via an API 86) makes the 
20 application appear to be available to the user, including 
writing information to the system registry 88 and adding 
script information such as shortcuts to assigned programs to 
the user profile 90 (e.g., the Start menu or desktop) on the 
workstation (e.g., 20i) . 
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Assigned applications are thus advertised, i.e., they 
appear as available to a user at each logon (if assigned to a 
user) or at each re-boot (if assigned to a machine) . Note 
that advertised applications are not necessarily installed on 
5 the workstation 20 lf but rather may only appear to be 
installed. To make an application appear installed, 
advertisements for an application include shortcuts that 
appear on the Start menu, a collection of registry 88 entries 
required primarily for OLE and shell activation, and icon 
10 files. For example, to explicitly launch an application, 
users navigate the Start menu looking for a shortcut 
representing the application, then click that shortcut. Users 
also implicitly launch applications by double-clicking a file 
(of a file system) having an extension associated with a 
15 particular application. If not already installed, assigned 
applications are automatically installed in response to file 
activation and other types of activation. 

Assigned applications are also resilient, in that they 
will be re-advertised on the next logon (or machine re-boot as 
20 appropriate) if deleted from the local workstation (machine) 
20i. To this end, the advertise script 82b for the user is 
reapplied at each logon (or another script for the machine at 
reboot), whereby the policy-specified applications for that 
user (or machine) are advertised on the workstation 20i. 
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Moreover, even if a user installs another program or different 
version of the application over an assigned application, 
because the advertise script 82b is reapplied, the assigned 
application (the administrator-specified version) will return 
at the next logon (or reboot, if assigned to the machine) . 
Only an administrator (and in particular a domain 
administrator) may permanently remove an assigned application, 
by doing so via the centralized location. 

Alternatively, a published application is an application 
that is available to users in a group or organizational unit 
into which it has been published, however unlike assigned 
applications, published applications do not appear installed 
on a desktop. For example, the administrative action of 
publishing an application does not make a reference to that 
application appear in a user's Start menu. In general, a 
published application has no presence on a user's machine 
until the published application is automatically or manually 
installed on a desktop, i.e., the application becomes assigned 
to the user's profile. More particularly, published 
applications (those set for auto-install) are automatically 
assigned to a user's profile when activated by clicking on a 
file with an associated file extension or via ClassID 
activations. Moreover, a user may manually install a 
published application such as via an ^Add/Remove Programs" 



applet dialog box or the like. Once a published application 
is installed, the user sees the application as if it was 
previously assigned, however, unlike an assigned application, 
if the published application is removed, it will not be 
5 present at the next user logon. 

Once advertised, the applications may be installed on the 
local workstation 20i by the managed software installer 
mechanism 8 6 (sometimes referred to as the Windows® Installer) 
on an as-needed basis in the file system, e.g., as Program 
10 Files 96 (FIG. 4), the place where the actual application 
O files are stored. For example, the first time that a user 
^ activates such an application (e.g., via the Start menu), the 
^ managed software installer mechanism 86 looks for it on the 
^* local machine but does not find it, after which the managed 
||p software installer mechanism installs the application from an 

application image 98 (FIG. 2) on a network server 100. 
;|0 Thereafter, the application remains on the local workstation 
20i and need not be re-installed, unless deleted in some 
manner. However, even if deleted, the assigned application 
20 will be re-advertised the next time policy 62 is applied, 

e.g., at the next user logon, whereby if again activated, the 
advertised application will again be re-installed. In this 
manner, applications are automatically deployed in accordance 
with a policy, but for purposes of efficiency, initially may 
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be only advertised rather than installed. As can be readily 
appreciated, installing programs only if and when activated 
provides substantial benefits, including efficient use of 
workstation resources, rapid user-logon, and balancing of the 
5 load on the network servers. The on-demand installation of 
software implementations including applications (e.g., 
features, components and files) is described in United States 
Patent Application Serial No. 09/158,022 entitled ^Method and 
System for On-Demand Installation of Software Implementations" 

0 10 and Serial No. 09/158,021 entitled ^Software Implementation 
Installer Mechanism," assigned to the same assignee as the 
present invention and hereby incorporated by reference herein 

:^ in their entireties. 

5 15 RELATIONSHIPS BETWEEN DEPLOYED APPLICATIONS 

iip In general, the present invention provides a method and 

system for managing the relationships between deployed 
software implementations (e.g., applications and operating 
systems) , and in particular, the precedence relationships 
20 therebetween. For example, the present invention may be used 
to deploy new software implementations, upgrade existing 
software implementations, remove software implementations, and 
so forth. Thus, the present invention applies to software in 
general, however, for purposes of simplicity herein, the 
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present invention will be primarily described with reference 
to relationships of application programs. Notwithstanding, 
the present invention is applicable to virtually any type of 
software implementation, including applications and operating 
5 systems . 

An administrator specifies precedence relationships 
between any desired applications deployed in the enterprise . 
As described below, this precedence is applied to the subset 
of applications that may apply to a given user or computer, to 

10 determine the actual set of applications that should be 

installed. The actual set is then compared against the list 
of applications already installed, and any required 
installation is performed. 

FIG. 5 represents the set of applications 102 available 

15 in an enterprise E, while subsets 104, 106 represent the 

applications made available by one or more group policies 62 
to two groups of users, Gi and G 2 , respectively. The subsets 
108, 110 represent the applications that are actually 
installed on two users' machines, U x and Uy, respectively. 

20 Also, in FIG. 5, the arrows represent the upgrade 

relationships between applications, e.g., Al is an upgrade to 
A5 and A6, (note that A6 is an upgrade to A8), A2 is an 
upgrade to A4 and so on. Note that A3 is installed on the 
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machine of the user U x and is an upgrade to A9, even though A9 
itself is not available to the user. 

FIG. 6 shows how the logon process 84, along with an 
upgrade process 112, (which may be part of the logon process 
5 84 or a separate component therefrom) , generally operates to 
apply the correct applications to a user's machine. As 
described in more detail below, the logon process 84 evaluates 
the group policy or policies 62 that apply to the user, and 
compares the list of applications therein against the state 

10 information 114 of the user's machine. The effective result 
is a list of applications 116 that are potentially available 
to the user. However, rather than advertise these 
applications to the user, the upgrade process 112 first goes 
through the list 116, and based on upgrade precedence 

15 information stored with the applications' properties in the 

class store 64, determines whether to set the applications for 
install and/or uninstall. 

For example, as shown in FIG. 5, Al is an upgrade to A5. 
If Al is to be presently upgraded, e.g., the upgrade is 

20 mandatory, A5 effectively will be removed, e.g., not marked so 
as to * apply" from the list of applications to apply. 
Moreover, if A5 is installed on the machine, it will be 
overlaid by Al rather than separately uninstalled, due to the 
upgrade/overlay property setting on Al. More particularly, 



certain upgrade applications are capable of properly 
overwriting the application or applications being upgraded, 
(e.g., writing over some files and/or deleting others), such 
as when both are written by the same manufacturer and the 
5 upgraded application is a recognized version. However, the 
upgrade application may not be able to (or know if it is able 
to) properly overwrite other applications, whereby those 
applications should be removed before replacing, sometimes 
referred to as a *rip and replace" operation. The property 

10 setting, either * overlay" or * replace" instructs the upgrade 
process on which way the install / uninstall should proceed. 
In the present example as represented in FIG. 6, Al is set for 
install, which will overlay A5. Conversely, had Al had the 
* replace" property value with respect to A5, Al would be set 

15 for install while A5 would be set for uninstall. 

FIG. 7 shows a model of a typical application lifecycle, 
beginning with the state where a version N of an application 
is deployed. At some time later, version N + 1 is obtained by 
the enterprise, as an update to or a replacement for version 

20 N. At first, the enterprise deems it desirable to make 

version N + 1 available to only a subset of version N users, 
ordinarily to test out the application's effects on the 
environment, referred to herein as a pilot stage. As testing 
proceeds, (assuming no major problems are encountered) , the 
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set of users that version N is available to may be increased, 
referred to in FIG. 7 as the rollout stage. Eventually, it is 
deemed desirable to make the version N + 1 the default 
application, whereby essentially all new users will get 
5 version N + 1 instead of the older version N. Version N may 
then be retired from service, which is accomplished in one of 
three ways. A first way is to force the upgrade to version N 
+ 1 by making it mandatory for all appropriate users (until 
that time, it had been optional) . An alternative way is to 

10 disable the application, followed by its removal. In this 
scenario, existing users of version N may continue using it, 
however no new users will be permitted to use it. Eventually, 
version N is completely removed from management, i.e., non- 
supported. Third, a forced removal may be designated. In a 

15 force removal scenario, all users of version N are forced to 
stop using it. The users may optionally use version N + 1, or 
they can use no version at all. Property values set on the 
application determine which upgrade scenario will take place 
for a given group. 

20 Turning now to an explanation of the operation of the 

present invention with particular reference to the flow 
diagrams of FIGS. 8 - 10, FIG. 8 shows general preprocessing 
steps for determining which applications to apply to a user or 
machine. As described above, the applications that may be 
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applied to a user or machine are those that are assigned 
thereto, along with those applications published to a user 
that the user has selected* For purposes of simplicity, the 
present invention will be described herein with respect to 
5 applications being deployed to a user at logon time, however 
as can be appreciated, the present invention is similarly 
applicable to applications deployed to machines, such as when 
the machine reboots and connects to the network. In any 
event, step 800 selects an application from the policy 

10 object's 62 (FIG* 6) list of such managed applications 

maintained in the class store 64 in accordance with the user 7 s 
group. Step 802 then checks to see if the application is 
assigned to the user, i.e., the group policy 82 deems it 
mandatory for that user. If so, step 802 branches to step 808 

15 where the application (e.g., a property thereof) is marked so 
that the application will be one applied to the user as 
appropriate. 

If not assigned, step 802 instead branches to step 804 
where the machine's state information 114 (FIG. 6) is 
20 evaluated to see if the user has previously selected it. Note 
that the application is either published or assigned, 
otherwise it should not be among the applications listed under 
the user's group policy or policies 62. Applications that are 
published and have been previously selected are similar to 
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those that are assigned, (except that as described above, the 
user can optionally remove such an application, which 
effectively deselects the application) . Thus, for 
applications published and selected, step 804 branches to step 
5 808 to mark the application for applying to the user. For 
published applications that have never been selected or that 
have been deselected, step 804 branches to step 806 where the 
application is marked (if necessary) so as to not apply it. 
Note that instead of marking the applications, effectively 

10 generating the list 116, it is alternatively feasible to add 
only the applications to apply to a new list, i.e., the list 
116 can be a separate list. In any event, the steps of FIG. 8 
are preliminary steps, which, although not necessary to the 
present invention, identify a set of possible applications to 

15 consider applying to the user. 

When the list of applications has been processed as 
determined at step 810, FIG. 8 continues to FIGS. 9 and 10 
which may modify the applications the user ultimately receives 
based on any precedence (upgrade) relationships between the 

20 applications in accordance with one aspect of the present 

invention. Note that as used herein, the term * upgrade" does 
not necessarily correspond to changing to a more recent 
version of the same application, (although such an upgrade 
would be typical) . For example, an administrator may select 
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one manufacturer's application program over that of another 
manufacturer. Similarly, an older version of a program may be 
put back into use, such as if the newer version failed to 
appropriately perform, whereby the older version would be an 
5 ^upgrade" to the newer version. Indeed, a program need not 
upgrade the same type of program or programs, e.g., a word 
processor with spreadsheet capabilities could upgrade both an 
existing word processor application and a spreadsheet 
application. 

Q 10 To handle the precedence relationships, step 900 of FIG. 

fU 9 selects (initially, the first) application in the list that 

m is to be potentially applied, as the current selected 

IM. application. Step 902 then determines, by evaluating 

;L properties stored with the applications as described above, if 

15 this application is an upgrade. If not, step 904 branches to 
;fi step 910, which continues the process by returning to step 900 
to select the next application and so on until no more 
applications remain in the list. However, if at step 902 the 
application is an upgrade, step 902 branches to step 904 to 
20 select an application that is to be upgraded by the current 
application, as listed in the properties therefor. Note that 
an application may upgrade more than one application that 
would otherwise be deployed to a user. 
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Step 906 then examines the state of the machine along 
with the application's properties to determine if it is 
currently installed for a user or set to be installed. Note 
that one application may be processed before an application 
5 that upgrades it is processed, and thus it may be already set 
for install (via step 1002, described below) . Further, note 
that as described above, an application that is available to a 
user may be advertised to the user, but not yet installed. In 
this type of configuration, installation only takes place when 
^ 10 needed, on demand, whereby among other benefits, the load on 
fjj the server is distributed and the local machine's resources 

W not burdened with unused application programs. If the 

TO application is neither installed nor is set to be installed, 

there is nothing to upgrade, and step 906 branches to step 908 
;^ 15 to determine if another application is to be upgraded. If so, 
it- step 908 returns to step 904 to evaluate the next application 

* TJ to be upgraded, otherwise step 908 branches to step 910 to 

test if another application is in the list, as described 
above . 

20 If at step 906 the application to be upgraded is 

currently installed or set to be installed, step 906 branches 
to step 1000 of FIG. 10. Step 1000 tests to determine if the 
application is to be upgraded now, i.e., presently, as part of 
this user logon. An upgrade takes place presently if either 
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it is mandatory, (as opposed to optional), or if the user has 
requested it now, such as by having clicked on a file with an 
appropriate extension, or via an Install Programs applet. 
Note that if the user is requesting to upgrade to an optional 
5 application, (e.g., via the applet) the upgrade / installation 
does not wait until the next logon time, however, it is 
essentially the same as upgrading at logon, but having only 
one application in the list to apply. If the upgrade is not 
mandatory or being requested by the user, step 1000 branches 

10 to step 1010 which sets the current application so as to not 
apply, and then returns to step 908 of FIG. 9. Step 1000 thus 
enables an administrator to distinguish between forced 
upgrades and optional upgrades, i.e., if the upgrading 
application is not set to upgrade now, then at step 1010 it is 

15 configured to not apply. 

However, if the upgrade is to take place presently, step 
1000 continues to step 1002 where the current (upgrade) 
application is set to be installed. Again, it should be noted 
that this will advertise the application, however the physical 

20 installation itself may or may not take place until the user 
first selects that application, depending on the 
administrator's choice. Step 1002 continues to step 1004 
where the overlay / replace property of the application is 
evaluated, to determine if it can be overwritten by the 



upgrade or needs to be removed, as described above. For 
applications that need to be replaced rather than overlaid, 
step 1004 branches to step 1006 where the application to be 
upgraded is marked for uninstalling. The uninstall may take 
5 place prior to installing the upgrade, which may be deferred 
as described above. Otherwise, step 1008 removes the 
application that is being upgraded from the list of 
applications 118, before returning to step 906 of FIG. 9. 
Once the upgrade process steps of FIGS. 9 and 10 are 

10 completed, the precedence relationships result in a set of 
applications to advertise to the user and possibly to 
uninstall, as essentially configured in the list 118 of FIG. 
6. The list 118 is compared against the actual state of the 
machine, and those applications set for install or already 

15 installed are advertised to the user as being available. The 
installs and uninstalls may take place immediately, or be 
deferred as described above. If deferred, the installs and 
uninstalls may wait for a user selection of the application, 
i.e., if the user selects an application that is not installed 

20 on the machine, any corresponding application marked for 
uninstall will be uninstalled, and the selected upgraded 
application will be installed on demand. Note that uninstall 
and / or install operations may be performed independent of 
user selection, such as during machine idle times and / or 
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periods of low network demand. For example, an upgrade to a 
large group of users, of a frequently used application such as 
a word processing program, can be performed to automatically 
install on a given weekend. This would prevent the network 
5 from becoming overburdened on Monday morning from too many 

installations, since many users are likely to first select the 
upgraded application at approximately the same time. 

As can be seen from the foregoing detailed description, 
there is provided a method and system that provide for 
10 managing precedence relationships between applications 

deployed in a network. The method and system are flexible, 
extensible and fit into an existing application deployment 
architecture to facilitate the management of deployed 
applications . 

15 While the invention is susceptible to various 

modifications and alternative constructions, a certain 
illustrated embodiment thereof is shown in the drawings and 
has been described above in detail. It should be understood, 
however, that there is no intention to limit the invention to 

20 the specific form or forms disclosed, but on the contrary, the 
intention is to cover all modifications, alternative 
constructions, and equivalents falling within the spirit and 
scope of the invention. 
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WHAT IS CLAIMED IS : 

1. In a network having software implementations 
deployed therein, a method for determining a set of software 
implementations to deploy to a client, comprising the steps 
of, maintaining information at a network location indicative 
of precedence relationships between software implementations, 
selecting a software implementation as a selected software 
implementation, determining if the software implementation has 
precedence over at least one other software implementation, 
and if so, setting the selected software implementation for 
deployment and deselecting the at least one other software 
implementation. 

2. The method of claim 1 wherein the step of setting 
the selected software implementation for deployment comprises 
the step of setting the selected software implementation for 
install . 

3. The method of claim 2 wherein the step of setting 
the selected software implementation for install comprises the 
step of including the software implementation in a list of 
software implementations to install. 
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4. The method of claim 1 further comprising the step of 
installing the selected software implementation* 

5. The method of claim 1 further comprising the step of 
advertising the selected software implementation as available 
to the user. 

6. The method of claim 1 wherein the step of 
deselecting comprises the step of setting the at least one 
other software implementation for uninstall. 

7. The method of claim 1 further comprising the step of 
uninstalling the at least one other software implementation. 

8. The method of claim 1 wherein the step of 
deselecting comprises the step of removing the at least one 
other software implementation from the set of software 
implementations to deploy. 

9. The method of claim 1 wherein the information 
indicative of precedence relationships between software 
implementations is maintained in a centralized class store of 
the network. 
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10. The method of claim 8 wherein the class store is 
associated with a group policy object provided for the client. 



11. The method of claim 1 wherein the information 
indicative of precedence relationships between software 
implementations is maintained in property values for the 
software implementations. 

12. The method of claim 1 wherein the information 
indicative of precedence relationships between software 
implementations includes a property value indicative of 
whether to replace or overlay another software implementation. 

13. The method of claim 1 wherein the client is a user, 
and wherein the step of selecting a software implementation as 
a selected software implementation automatically occurs as 
part of a user logon. 

14. The method of claim 1 wherein the client is a user, 
and wherein the step of selecting a software implementation as 
a selected software implementation occurs in response to a 
user request. 
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15. The method of claim 1 wherein the client is a 
machine, and wherein the step of selecting a software 
implementation as a selected software implementation 
automatically occurs when the machine connects to the network. 

16. A method for implementing a lifecycle for software 
implementations deployed in a network, comprising the steps 
of, maintaining policy information at a network location 
including software implementations to deploy to groups of 
clients and precedence relationships between the software 
implementations, receiving a request to deploy a software 
implementation to a client of a particular group, locating the 
policy information corresponding to the group, and determining 
from the policy information which software implementations to 
apply to the client based on the precedence relationships 
maintained therefor. 

17. The method of claim 16 wherein the step of 
determining which software implementations to apply to the 
client comprises the step of setting a first software 
implementation for install when the first software 
implementation has precedence over a second software 
implementation . 



- 34 - 



18. The method of claim 17 further comprising the step 
of installing the first software implementation. 

19. The method of claim 18 wherein the installation is 
mandatory. 

20. The method of claim 18 wherein the client is a user, 
and wherein the step of installing the first software 
implementation is optional for that user. 

21. The method of claim 16 wherein the step of 
determining which software implementations to apply to the 
client comprises the step of removing a first software 
implementation from a list of software implementations to 
install when a second software implementation has precedence 
over the first software implementation. 

22. The method of claim 21 further comprising the step 
of installing the second software implementation, wherein the 
step of installing the second software implementation overlays 
the first software implementation. 

23. The method of claim 16 wherein the step of 
determining which software implementations to apply to the 
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client comprises the step of setting a first software 
implementation for uninstall when a second software 
implementation has precedence over the second software 
implementation . 

24. The method of claim 23 further comprising the step 
of uninstalling the first software implementation and 
installing the second software implementation. 

25. The method of claim 16 further comprising the step 
of specifying the precedence relationships for the groups of 
clients . 

26. The method of claim 25 wherein the step of 
specifying the precedence relationships for the groups of 
clients comprises the step of specifying a pilot group of 
clients that is small relative to a total number of clients of 
the network. 

27. The method of claim 2 6 wherein the step of 
specifying the precedence relationships for the groups of 
clients comprises the step of specifying a rollout group of 
clients that is relatively larger than the pilot group and 
smaller than the total number of clients of the network. 
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ABSTRACT 

A method and system for managing the changing of software 
implementations such as applications deployed to users in an 
enterprise. Precedence relationships between any of the 
applications deployed in an enterprise are specified. To 
determine the actual set of applications that should be 
installed for a given client user or client machine, the 
precedence is applied to the subset of applications that are 
assigned or published to the client. To this end, at logon or 
machine reboot, an upgrade process walks through the deployed 
applications and evaluates the upgrade relationships 
therebetween, setting applications for removal or installation 
as appropriate . A user may also install an application that 
has been designated as optional for that user. The method and 
system facilitate the use of application lifecycles, a model 
for replacing applications with either new or updated 
applications. For example, administrators can phase in 
upgrades first as a pilot to a small group of users, roll out 
upgrades to a larger group, and then provide the application 
to all users. The upgrade may be mandatory or optional, while 
the programs that are being replaced may be removed and them 
replaced, or overlaid by installing the new application over 
the old. Other applications may simply be removed without 
replacing, while others may optionally remain but be non- 
supported. 

- 37 - 



Application*!, 
Published, Upgrade 
of Application 5, 
Overlay _ 

■ 

Application 10, 
Assigned 



List of Applications 
for Group 



114 
62 



Application^ 
Selected, Installed 

■ 

■ 

Application 5. 
Selected, Installed 

■ 
■ 

Application 2, 
Selected 



Machine State 
Information 




List of Applications 
to Potentially Apply 
A1,A2,A3,A4, 
A5, A6, A10 



116 



L „ 




112 



List of Applications 
Set for Install, 
Uninstall 



118 



FIG, 6 



0 

a 
ru 
is 

W 
fu 
m 

0 
$ 

c 
•id 



I 

o 

Q. 

CL 
3 

(/> 

I 

C 

O 



o 



•a 
o 

(0 
0) 



> 
o 

E 

<D 



73 

o 

i 

a. 
a> 
Q 



6 



2 



T3 
O 

|- 

Q. 

<D 
Q 



O 



(HHJi 



3 
O 

o 



ex 



6 



6 



c 
o 

1 

> 



FIG. 8 



No 

(Published) 





Mark 
Application so 
as to 
Not Apply 



808 



Mark 
Application so 
as to Apply 



FIG. 9 



900 



start 
FROM FIG. 9 

F= 



Select (Next) Application 
Marked Apply as Current 
Application 



902 



904 



Yes 



Is 

Current 
Application 
an Upgrade 



Select an 
Application to 
be Upgraded 



Yes 



C 



To / From 
FIG. 10 



Is it 
Currently 
Installed or 
Set to be 
Installed 

9 



No 



908 



Yes 



Another 
Application 
Upgraded by 



906 



910 



Another 

Application 

to Apply 
? 

'no 



Yes 



FIG. 10 



1000 



1002 



1004 



1008 



Configured 
to Upgrade 
Application 

Now 

*? 

'Yes 



Set Current 
Application for 
Install 



Remove Application 
being Upgraded From 
List of Applications 



1010 




Set Current 
Application so as 
to not Apply 



/ Yes 


1006 

- \ 


Set Application 
being Upgraded 
for Uninstall 



£ 



^ To FIG. 9 ^ 



PATENT 

Attorney Docket No. 1650 

COMBINED DECLARATION AND POWER OF ATTORNEY 

As a below named inventor, I hereby declare that 

My residence, post office address, and citizenship are as stated below next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, first, and joint 
inventor (if plural names are listed below) of the subject matter which is claimed and for which a patent is sought on the 
invention entitled: "Method and System for Managing Lifecycles of Deployed Applications," the specification of 
which is attached hereto unless the following box is checked: 

□ was filed on as United States Application Serial No. or PCT International Application No. 
and was amended on (if applicable). 

I hereby state that I have reviewed and understand the contents of the above-identified specification, including the 
claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to patentability as defined in 37 C.F.R. § 1.56. 

I hereby claim foreign priority benefits under 35 U.S.C. § 1 19(a)-(d) or § 365(b) of any foreign application(s) for patent 
or inventor's certificate, or § 365(a) of any PCT international application which designated at least one country other 
than the United States of America, listed below and have also identified below, by checking the box, any foreign 
application for patent or inventor's certificate, or PCT international application having a filing date before that of the 
application on which priority is claimed. 

Prior Foreign Application(s) Priority Not Claimed 

□ 

(Number) (Country) (Day/MonnVY ear Filed) 

□ 

(Number) (Country) (Day/Month/Y ear Filed) 

I hereby claim the benefit under 35 U.S.C. § 1 19(e) of any United States provisional application(s) listed below. 



(Application Number) (Filing Date) 



(Application Number) (Filing Date) 

I hereby claim the benefit under 35 U.S.C. § 120 of any United States applications), or § 365(c) of any PCT 
international application(s) designating the United States of America, listed below and, insofar as the subject matter of 
each of the claims of this application is not disclosed in the prior United States or PCT International applications) in the 
manner provided by the first paragraph of 35 U.S.C. § 1 12, 1 acknowledge the duty to disclose information which is 
material to patentability as defined in 37 C.F.R. § 1.56 which became available between the filing date of the prior 
applications) and the national or PCT international filing date of this application. 



(Application Number) (Filing Date) (Status - patented, pending, abandoned) 



(Application Number) (Filing Date) (Status - patented, pending, abandoned) 



1 



As a named inventor, I hereby appoint the following attorneys to prosecute this application and to transact all business 
in the Patent and Trademark Office connected therewith: 



Albert S. Michalik, Reg. 37,395; Daniel D. Crouse ? Reg. No. 32,022; Katie E. Sako, Reg. No. 32,628. 
Address all telephone calls to Albert S. Michalik at telephone number (425) 836-3030. 



Address all correspondence to 



The Law Offices of Albert S. Michalik 
704 - 228th Avenue NE 
Suite 193 

Redmond, WA 98053 



I hereby declare that all statements made herein of my own knowledge are true, that all statements made on information 
and belief are believed to be true; and further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such willful false statements may jeopardize the validity of the application or any patent 
issued thereon. 



Full name of sole or fir inventor: Stephen M^landing 
Inventor's signature 





Date ZS tVhpJ* *) 

Residence: 223 1 1 NE 62nd Place, Redmond, Washington 98053 
Post Office Address: Same 



Country of Citizenship: USA 




Full name of second joint inventor, if any: Michael J. Cherry 
Inventor's signature^ 
Date 

Residence: 17537 NE 142nd Street, Redmond, Washington 98052 

Post Office Address: same 




Country of Citizenship: Canada 



at inventor, if any: David E. Kays, Jr. 



Full name of third joint ^jnventor, if any: David E. Kays, Jr. 
Inventor's signature 
Date 



Country of Citizenship: USA 



Residence: 1 1 1 1 W. Lake Sammamish Parkway SE, Belle vue, Washington 98008 

Post Office Address: Same 

1X1 Additional inventors are being named on separately numbered sheets attached hereto. 



2 




Full name of fifth joint inventor, if any: Debi P. Mishra 
Inventor's signature 

Date ^ 



Country of Citizenship; India 



Residence: mQfr£FEr6 &d Way, Redm o nd Wasl iinglon 9S052 ?Ld KJo UK^/ RJL # 52 , 

Post Office Address: Same v ^ ! 



Full name of sixth joint inventor, if any: Daniel Plastina 
Inventor's signatw ^ ""^j^^ 
Date 3/24/99 




Country of Citizenship: USA 



Residence: 4409 229th Place SE, Issaquah, Washington 98029 

Post Office Address : Same 

d Additional inventors are being named on separately numbered sheets attached hereto. 

1650 declaration 



3 



